1 Introduction

Currently, ultra-competitive pressure in the marketplace is forcing companies to design and manufacture products with improved performance and quality while reducing costs, development and lead time and seeking improved innovation outcomes [1–3]. Kumar and Wellbrock [1] discover that engineer-to-order (ETO) companies in particular seem to lack strategies for adequate design and process control and consequently have difficulties in facing the challenges of progressively tougher marked demands. Incidentally, researchers suggest different approaches to improve processes for either manufacturing (e.g., zero defect manufacturing [4], data mining [5, 6], increased flexibility [7], mass customization [8], etc.) or product development approaches (e.g., set-based, concurrent engineering [9], continuous improvement [10], modular products [11], product families [12, 13], standardization [14], etc.).

Because all of these approaches require broad and extensive product and process knowledge, a fundamental prerequisite for any firm is to improve its capabilities in extracting valuable information and knowledge and turn it into a competitive advantage [15–17]. Therefore, organizations need to improve their learning capabilities. Furthermore, firms need to increase quality, estimate their own capabilities correctly, and reduce the risks of failing or delaying projects to achieve the goal of an improved product engineering outcome [18–20]. Nonaka et al. [21] argue that for effective organizational learning, the conversion between tacit and explicit knowledge is an essential factor. The tacitness of knowledge is reported as a barrier to its transfer [17]. Consequently, a fundamental criterion for the reuse and continuous improvement of knowledge is making knowledge explicit and visual [13, 22].

This study focuses on knowledge discovery for creating a base to implement a knowledge-based development (KBD) approach to improve new product development (NPD) outcomes. The starting point is a Norwegian ETO company, whose products are engineered and customized lightweight aluminum mast systems, which are primarily used for road traffic and aviation. The company’s product portfolio has grown over time across many customer specific ETO projects while staying within the same product range but without a clear product strategy or product organizational structure. The company is faced with two main challenges. First, product knowledge is project specific, and sources remain dispersed. Consequently, the full variety of the product portfolio is diffuse (tacit), indicating that it needs to be compiled and made explicit, and the historically grown product variety needs to be revealed. The second challenge is that product knowledge needs to be organized and structured to provide a clear, strategic base for future developments.

As one possible approach for ETO companies, Kuroda and Mihira [14] recommend establishing a product standardization and customization strategy based on product architecture and turning the ETO approach into a configure-to-order (CTO) approach. Thus, product components and assemblies, along with related processes and knowledge, can be more easily (re)used in different product configurations [23, 24]. Nevertheless, changing from an ETO to a CTO approach changes the product engineering processes within the organization. Thus, the importance of maintaining a system view increases [25]. A successful implementation of an architectural approach requires an extensive, multi-disciplinary analysis along with the alignment of products, processes, and market strategies [2, 25–28].

During a literature review, we discover tools and methodologies for product, product portfolio, and product architecture modeling (e.g., Refs. [13, 29–33]), providing representations of the product, interfaces, structures, architectures, and their combinations. Certain methods are based on experience or visual modeling, e.g., interface diagram [33], product family master plan [34], and product variant master [35]. Others take their initiative in mathematical modeling algorithms, such as the design structure matrix [30] or the K-means algorithm [7].

However, one aspect of the described approaches that remains to be debated is the practice of measuring success on the basis of a single product without considering other important aspects, such as historic growth in product variants within the portfolio [25]. The methods assume either new architectural developments or optimization of existing architectures, which presume that the product portfolio as well as solution space and its variations are already clear and systemized (explicit) across product deliveries.

It is suggested that a visual approach is required for mapping the product variance for the problem described above that can illustrate functional, physical and architectural structures across the different variants, which ensures that it is possible to detect true (functional, physical, and architectural) variants. To our knowledge, no adequate systematic methods are reported in the literature for approaching this type of situation, which directs us to posit the following research question: how can an existing (but tacit) group of similar ETO products––with a historically grown variance within the same product range––be identified, structured, and unified to detect commonalities and variances on a functional, physical, and architectural level?

In this regard, we establish a proof-of-concept (POC) demonstrator, one that aims to unify and map the current product portfolio while making tacit product knowledge explicit. Our goal is to create a transparent overview of the product portfolio that can be used as a basis for implementing a robust product architecture supporting knowledge-based approaches. Hence, our research method includes a literature review to critically analyze relevant, valuable product architectural development theories and product portfolio analysis methodologies. Identified gaps are going to be filled by the POC study. For the latter, we have studied the current state and historical variety in the product portfolio of the introduced company by revisiting different sources for product knowledge and documentation. Figure 1 summarizes the desired result of this research, which is to determine a method to convert an unclear, unstructured product portfolio into one unified, systemized product portfolio overview.

Fig. 1
figure 1

Desired result of this research

Full size image

The overall structure of this paper is as follows. Section 2 reviews and synthesizes the relevant literature within the field. Section 3 provides a proposition of a KBD framework as a long-term implementation goal. Section 4 presents the research method and introduces the company used for the POC demonstrator. Section 5 presents the analyses of the POC demonstrator. Section 6 provides a discussion of relevant conditions and usefulness of the concept. Section 7 concludes with a summary and further outlook.

2 Literature review

In the introduction, numerous terms (e.g., product portfolio, product architecture, modularization, KBD, etc.) have been introduced. Because various definitions exist in the literatures, we will briefly review the definitions as they are applied in our study and discuss their main characteristics. Furthermore, we will review product modeling methodologies, and discuss the manner in which they can be applied in this study and identify gaps. Information is gathered primarily from recent research found in journal and conference articles in the lean product development (LPD) and engineering design fields that focus on approaches that combine systems engineering, product development, and knowledge from both product development and manufacturing perspectives.

2.1 KBD

In this study, we understand KBD to be a part of the LPD framework, as presented in Fig. 2. The overall framework of the addressed topic is the concept of “lean” applied to all entities of the organization, including lean manufacturing, lean processing, lean management, lean logistics, etc. [36, 37], as well as the connectivity between the entities within the enterprise system. When aiming to extend the lean concept beyond manufacturing and up the value stream to NPD [38, 39], standardization, knowledge management processes, customer value, etc., are all parts of LPD [36]. In this paper, we focus on the knowledge-related portion of LPD, where the ambition is to continuously improve the way that the products are developed [18]. Ulonska and Welo [40] demonstrate that the two concepts of LPD and KBD are equal in many aspects. Subsequently, we apply the term KBD here because product knowledge transfer and retrieval are the focus of this paper.

Fig. 2
figure 2

KBD in the lean enterprise

Full size image

However, the fundamental principle of “lean” is a way of working and thinking about company-wide processes with a focus on effectiveness and efficiency [39] without providing specific guidelines on how to establish a system for managing product evolution with a documentation basis in product knowledge [40]. To structure a product portfolio, other tools from engineering design methodologies need to be applied, e.g., Ref. [41], which provide concrete steps for achieving engineering excellence [40]. One approach, which supports standardization and product evolution, is a product architecture [19]. Consequently, we have added the product architecture and related engineering design topics to our KBD model (see Fig. 2).

A combination of both traditional engineering design methodology and KBD appears to be a suitable strategy for determining an approach to map the product portfolio. KBD may add effectiveness, reduce waste, and increase competiveness to the traditional engineering design approaches. It provides the capability for methods to evolve and be more suitable for current competitive challenges.

2.2 Product architecture

One commonly applied standardization approach in engineering design is to establish a product architecture [25] and thereby the possibility of creating several variants from the same basis product [42]. In this paper we use the following architecture definitions [43]: (i) arrangement of functional elements; (ii) mapping of functional elements to physical components; and (iii) the specification of interfaces between components. An architectural approach for multi-product development may include the reuse of concepts, components, processes, and knowledge and thus the potential for decreasing total cost, reducing lead times and parallel processing [11, 28, 42, 44, 45].

According to Harlou [13], product architectures consist of design units, standard designs, and interfaces. Standard designs comply with several product variants and can be reused over time [25]. The design units are elements that differ across variants and are consequently not reused. Hence, when analyzing the product portfolio, both standard designs and design units will have to be discovered when aiming for a common architecture with customization aspects. When establishing a CTO approach, standard designs become the common basic designs while adding customized design units will serve certain customer requirements.

2.3 Product architecture implementation

The implementation of a product architecture will influence all product-related actions, including product management, product organization, and knowledge management as well as production processes and product distribution. When implementing this approach, one has to be aware of company-wide changes, otherwise the change from an ETO to a CTO approach might fail [22]. The consideration of all organizational factors closes the loop from a pure architectural engineering design approach to a system-wide, lean, organizational approach. The factors introduced here are going to be included in the KBD approach introduced in Sect. 3.

2.3.1 Front loading

To achieve an organization-wide alignment, an architectural approach requires heavy front-loading of the NPD process, which reflects several different external market-related factors (e.g., core competency, power of buyers, market plan, innovation pace, etc.) [46, 47]. Furthermore, internal process-related factors have to be considered [24]. Consequently, when designing a modular, architectural product system, the up-front investment and work load will be considerably higher [48]. Hence, an organization needs to be confident that the value created long-term offsets the investment. This approach requires an analysis of target customers and establishing a deep understanding of what creates value to them [49]. Hence, when to determine standard designs, common and special customer requirements needs to be identified.

2.3.2 System view

To successfully adapt the architectural design to influencing factors [25], a strong collaboration between company departments and a unified systems engineering approach are required. Sanchez and Collins [19] and Mortensen et al. [25] argue that it is necessary to complement the traditional product view with both process and market views. Mortensen et al. [25] further suggest that product, process and market architectures have to be aligned. For an approach to become effective, standard designs need to be selected in a way such that they meet in-house capabilities, such as manufacturing, and cover the vast majority of different customer requirements [22].

2.3.3 NPD project execution

A product architecture may change the way of executing NPD projects [50]. The design strategy includes developing solutions to provide a well-defined product portfolio with clear variants intended for satisfying current and future needs. Thus, the NPD process becomes more predictable, flexible, and effective and less dependent on the desires of individual customers [42].

2.3.4 Customer

One challenge with an architectural approach is to guide customers in the direction of standardized solutions [47]. Product architecture components are developed to satisfy a certain performance range (target) rather than a specific set of firm requirements. Unlike the case of an ETO product, where the customer can more or less define the product outcome, the customers have to select a product that best satisfies the requirements, which may lead to confusion [51]. Although there are certain customization possibilities [52], the challenges, however, are motivating customers to select a solution that generally relies on pre-developed concepts [47]. One advantage for the customer is better predictability of deliveries or uncertainties, which results in a more robust product.

2.3.5 Knowledge management

The product architecture may serve as a knowledge management tool [19]. Assuming that the product, process, and market architectures are fully aligned, an organization can establish a better overview of its own capabilities and bottle necks and thus identify knowledge gaps [2]. Hence, product developers are encouraged to discover and diagnose deficiencies in their knowledge base [53]. One approach for combining product architecture with knowledge management will be described further in Sect. 3.

2.4 Visual product architecture modeling

The methods introduced here establish a base for structuring the product portfolio, as described in Sects. 4, 5 and 6. Research in architecture design methods provides different approaches to the task of modeling a product and its architecture. Several of these methods are based on mapping the functional structure and relating them to physical modules [25]. Table 1 provides an overview over the methods we considered in this literature research.

Table 1 Product architecture modeling methodologies
Full size table

Most of the product architecture modeling methods have their origin in engineering design methodology, e.g., Refs. [54, 55]. Here, Mortensen et al. [25] identified a number of different approaches, such as function-based methods, experienced-based methods, mathematical methods, and general feature-based methods. Harlou [13] and Mortensen et al. [25] recommended modeling and visualizing product dependencies in the design phase of an architecture, arguing that visual structures have strengths in cross-organizational architecture design and making product knowledge explicit. Because the goal of this study is to make a tacit product portfolio explicit and implement an approach across many variants, we also focus on visual methods.

The basic structures in engineering design are the visual functional structure (abstract level) and the physical structure (detailed level) of the product [54, 56]. The functional structure is a basis for implementing standard designs and architectures [58]. It is often independent of specific physical solutions that may evolve over time [13], which makes it to be one of the essential structures when modeling a product. The second essential structure is the physical structure because it defines the actual build-up of the products and possible modules [56]. Göpfer [56] combined these two basic structures visually, illustrating “how-why” relationships between the abstraction levels. Thus, the basic architecture, as defined by Ulrich [43], can be modeled but other elements as dependencies between the architecture and principal solution, product variants, or hierarchical structures are not defined. Hence, in addition to these two basic structures, several extensions and variants are used to model the product in a wider perspective.

For example, Ulonska and Welo [57] combined the functions and physical structure with the schematic product diagram to create an overview of components, functions and their relation and arrangement in the principal building structure. In this study, the inclusion of the complete building structure will excessively blow up the model because it describes one product variant at a detailed level. However, the visualization of the principal product layout may be a useful contribution for an easily understandable portfolio overview.

Furthermore, the interface diagram [32] provides the capability of capturing the structural characteristics of a system. It maps the system between domains as well as between function and form. The diagram is a tool that visualizes multi-disciplinary dependencies but concentrates on a single product and can not display several product variants concurrently.

When considering more product variants, another visually oriented approach is the product family master plan (PFMP) [13]. Here, large quantities of information are presented in a poster-format and arranged in customer, engineering, and physical part views. The PFMP facilitates visualization of multiple product views in a single model. This model can illustrate many variants in parallel but misses the functional structure and the interfaces between the abstraction levels. Additionally, the product variant master [35] aims to function as a mediator between different products, processes, and IT-experts. It describes classes (e.g., components, assemblies, or principle classes) and their relations and properties in two generic sections, called part-of and kind-of structure. Similarly, the UML class diagram describes object classes, their properties, and relationships [60]. Comparable to the PFMP, these approaches do not include the functional modeling components.

Other non-visual approaches, e.g., the design structure matrix, apply algorithms to decompose components and systems as well as identify interfaces and thus cluster the product [30]. The design structure matrix (DSM) is not applied in this study but its mindset related to the understanding of components and modules is a useful contribution for identifying standard designs or determining preferable architectural configurations.

2.5 Discussion of the literature review

However, one weakness of the visual product architecture modeling approaches is that they do not provide the capability of showing the variance of different product deliveries in parallel. Moreover, the product variants or common systems that go across the variants are difficult to identify. A visual approach is needed for mapping the product variance for the POC demonstrator that can illustrate the functional, physical, and architectural structures across the different variants. This approach should make it possible to detect true (functional and physical) variants. The functions, physical parts, and their relations need to be defined because they are essential elements of product structuring and description on an abstract and detailed level. The introduced approaches can model elements, but a combination of these approaches has been applied to establish a product portfolio overview.

3 Proposed KBD model

Our study addresses both organizational and engineering aspects of the product architecture, and it applies visual methods for product mapping, which is driven by the desire to create a company-wide engineering framework for more effective product engineering. Hence, before we introduce a method to discover product knowledge by establishing a product portfolio overview, we will introduce our model as a proposition for KBD (see Fig. 3b). Our model applies the product architecture as an engineering design tool within a KBD framework. The proposed NPD strategy is to divide the value creation into a knowledge value stream with a product architecture as the backbone for cross-variant product evolution and a product value stream for addressing special customer requirements and executing CTO projects.

Fig. 3
figure 3

Current reuse of product knowledge and desired future approach

Full size image

According to Kennedy [62], a value stream exists across different projects in every company that represents the dynamic knowledge standard of the company. Additionally, Shook [20] recommends a (mental) model consisting of two value streams (product and knowledge). The knowledge value stream may serve as a platform, based on standard designs, that evolves over time as product knowledge improves. At the same time, the product value stream may serve to derive product variants out of a predefined set of design elements to comply with certain customer-specific orders [25].

Generally, functionality and architectures do not frequently change along product generations, conversely solution principles or detailed designs may change due to technical progress [30, 63]. Hence, with an architectural approach, the modules can evolve independently and be substituted by upgrades when desired [64].

The challenge is to integrate both value streams because this affects all products and processes in the organization [65]. Another challenge is that the development of products using the same (existing) architecture in an CTO approach may hinder an organization’s ability to implement novel architectures in the future, thus failing to develop or delay product innovations that do not fit the architecture [66].

4 Methodology to map the product portfolio

In the above literature review, different architecture modeling methodologies were examined with regards to visualization capabilities. However, none of them is entirely suitable for structuring the product portfolio as desired, although each one contained useful capabilities that could be combined to create desirable visual overviews. To explore features of a suitable visual representation, we combine several methodologies and create large product maps in poster format.

To verify the concept of our product portfolio modeling, a POC demonstrator [67] method has been selected using products of a Norwegian SME. This particular company has identified problems in reusing product knowledge that resulted in the company investigating the opportunity of changing their product strategy from an ETO to a CTO approach. The products of the company are relatively simple: customized lightweight aluminum mast systems in road traffic and aviation applications that are used for supporting signs, control systems, signal lights, cameras, etc. The low product complexity allows the selected mapping methodology to be easily testable and understandable. Despite the relatively low complexity of the products, it is still applicable to test the functionality of the mapping methodology, which results in the company being a suitable research case as a POC demonstrator.

4.1 Introduction of the company used as POC demonstrator

The company develops different accessories for the mast systems, including connectors, clamps and foundations, which are required to provide a complete (ready-to-install) system. Manufacturing these components in-house is not considered strategically important and is thus outsourced to suppliers. The development, sales and distribution are located in Norway while the products are manufactured in Sweden, assembled regionally, and distributed globally.

The company has several international customers, all with widely different requirements, depending on local legislations for traffic and aviation standards, road widths, tunnel safety regulations, airfield safety, etc. As indicated, the products are developed in traditional ETO projects. Although the different product deliveries have much in common, such as structural shape configuration and low volumes, the variance at detail level is high. Consequently, significant reengineering must be performed in each project to accommodate specific customer needs.

Prior to this study, the company had already made sporadic efforts in standardizing production, sales, and logistics operations. For example, the number of mast cross sections has been reduced to four standard variants to cover the entire application range. Additionally, the product portfolio has been standardized into kits and subsystems to reduce the number of variants.

4.2 Problem formulation

The company’s business strategy essentially includes offering incremental product innovation based on an existing product portfolio. Currently, there is no common product architecture implemented, similar to the situation in many mature ETO companies, as discovered by Colosimo et al. [23] and Matta et al. [68]. The design, engineering and development practices resemble a “copy-and-paste” approach, as illustrated in Fig. 3a. The preferred solutions from earlier customer-specific ETO projects are adopted in new projects. Subsequently, they are reconfigured and reengineered to comply with new requirements, customer needs, rules and regulations, and the most recent state-of-the-art technology. Because of the vast amount of customization between projects, which generally occurs in the later project phases, it is difficult to establish a documentation standard that makes information accessible and reusable.

Kennedy et al. [9] discovered that when project schedules, detail requirements and the product concept were set early, it tended to lead to the late appearance of critical knowledge gaps, which in turn resulted in design loopbacks. The outcome is typically project delays, costs overruns, lack of organizational learning and ultimately the same type of problems occurring in future projects. Another undesirable tendency is that late changes have a tendency to create a drift towards increased variance and complexity because modifications are made reactively to accommodate late discoveries of knowledge gaps in each project, as discussed by Colosimo et al. [23], Haug [29], and Henriksen and Rolstadås [69].

Furthermore, the company lacks an internal knowledge repository, which provides fact-based, reusable knowledge generated in earlier NPD projects. This makes it difficult for individuals to find relevant product information because the knowledge (at best) is with individual employees rather than within the standards and operational procedures of the company.

4.3 Analyzing the product portfolio

Figure 4 summarizes the steps performed to analyze the company’s product portfolio and subsequently establish a portfolio overview. The initial situation included a product portfolio with an unspecified, less-than-optimal, tacit knowledge base in separate functions within the company. This portfolio included several product variants that were essentially similar or had identical functionality accommodated with different designs. Sub-system and domain experts were interviewed to obtain the required input information, such as manufacturing capabilities, product build-up, functional requirements, different physical solutions, etc.

Fig. 4
figure 4

Steps to analyze the product portfolio

Full size image

A selected group of road traffic products was systematically studied to determine the product limits in terms of performance, configurations, variants and product properties, as recommended by Hansen et al. [47]. They define a number of external factors that influence the establishment of product architecture (e.g., market launch speed, formal justification, market position, physical constraints, volume per variant, or customization solution space, etc.). Moreover, the method in which technical problems were solved was examined in terms of overall architectural layout, functionality, principal solutions, and detailed design. A top-down approach was applied, starting by analyzing the products and their variants at system level and mapping them into a product portfolio map.

It was challenging to collect product information because it was provided by various sources (e.g., product catalogues, excel sheets, reports, manufacturing drawings, oral information, etc.). Occasionally, information was misaligned, outdated, or coded using different systems, which made it difficult to identify commonalities. Consequently, it was decided to distinguish between variants that were truly different and those that initially seemed different but turned out to describe virtually similar product variants.

As a first step (see Fig. 4), product catalogues and delivered products were analyzed to identify product information at the system level, including product families, product organization, and modules. According to Haug et al. [70], a successful approach for graphical product knowledge models is to arrange a series of modeling sessions where all relevant sub-system owners discuss the contents of the models. Thus, the steps illustrated in Fig. 4 were repeated iteratively after being discussed with the case company’s engineering experts.

5 Product portfolio analysis

Figure 5 provides an extract of the established portfolio map for the case company’s road traffic products. The map is reduced to one or two variants per superior selection to ensure it fits the paper size for illustration purposes. Hence, the map does not provide the entire product portfolio map, which covers a much wider range of variances. However, the visualization provides enough information to explain its primary principles.

Fig. 5
figure 5

Product portfolio map for road gantries provided by POC Company

Full size image

The portfolio map structures the portfolio into four different levels (represented by the four major rows): principal layout, architectural variance, functional variance and physical variance. The number of variants increases as the solution becomes more specific. In other words, there is a lower variance on an architectural level than on a physical level. The grey arrows between the rows allocate the variant to the respective selection on the superior level. Certain systems are consistent across the variants, and a feature that is symbolized by the boxes placed in the background of each row. The common systems are the four mast types with each having a different cross-section, which represents the underlying building parts for all variants. The horizontal lines going across the variants depict the different mast types.

The first row lists the principal layouts of available products. Thus, these are the layouts that present the rough principal product that customers can choose from. For example, alternative products are single masts, gantries, tunnel gantries or T-gantries.

The second row represents the architecture with linkages to the principal layout of the row above. The products’ primary functions, which are to support the framework in the horizontal and vertical directions, are introduced on the line of the accordant mast-type (see Fig. 5) to indicate the common system used. Different architectural layouts can be applied to produce a mast with the same principal layout. For example, a T-gantry can be assembled using two masts with a 200 mm × 200 mm cross-section, two masts with a 250 mm × 250 mm cross section, or one mast with a 200 mm × 200 mm cross section and one mast with a 250 mm × 250 mm cross section. The selection of the architectural layout is dependent on superior factors, such as geometry, required strength, and product environment.

The third row presents the functional variance. The functional build-up of the road traffic products is relatively simple because the main function of these masts is to provide support of a sign, street light or traffic system (under different load conditions) while providing a soft barrier in impacts. The primary functions of the architectural layout are decomposed in the third row, showing sub-functions and functional flow, which are dependent on the selection in the superior row. Due to different customer requirements, it is necessary to accommodate a certain functional variance. For example, additional functions for safety need to be included in certain deliveries.

The bottom row in Fig. 5 illustrates the physical variance of the products, which is dependent on the selection of the principal layout, architectural variant and functional variant. The physical solutions provide the functions of the specific variant selected above. Different physical variants can be selected as a customer option to fulfill the functions of the row above. Certain variants use an integrated design while others use a modular design, which divides the system into modules, as illustrated by different shadings. The physical building blocks are arranged similarly to the functions in the row above. Thus, the relation between function and physical part can be detected.

6 Discussion

The product portfolio map reflects the current product variants within the company at system level, including all necessary levels of abstraction discovered in literature review. Although the approach visualizes a comprehensive overview of the product portfolio, it also has certain limitations. The map does not give direction for (re)structuring or consolidating product variants or serve to assess variants against each other, although it presents similar variants in parallel. To determine the most promising solution for the representation of a standardized architecture, the application of other methodologies also has to be evaluated. Furthermore, data have been collected and mapped through as objective evaluations as possible, although the approach used may still provide bias.

One challenge in creating the map is to determine a balance between the need for overview and the need for providing details at a product engineering level. When considering too many details, the number of variants escalates, which makes it more difficult to distinguish the unnecessary variants from the necessary ones. When considering the collaboration between different sites, this type of mapping in MS Visio may be challenging because it is not applicable via online tools. Because the POC in our research case has just one development site, it is not an issue.

Nevertheless, the developed product mapping methodology provides a practical method of transforming fragmented and dispersed information into visually organizational knowledge. Furthermore, this methodology enables visualizing structured product deliveries while highlighting commonalities and differences between different options. Variants that were earlier unknown could be systemized and visualized in a unified map.

7 Conclusions and outlook

To make tacit product knowledge more explicit and reveal historical development in product variety, a product portfolio has been developed, established, and tested in a POC demonstrator. The mapping methodology is a starting point towards a structured product portfolio. The current product variant properties can be identified by simultaneously visualizing variants on architectural, functional, and physical levels and a principal layout. The mapping methodology unifies product knowledge of various sources. Thus, a clear knowledge perspective has been established together with a more systemized product portfolio.

The establishment of a product portfolio map answers the research question by presenting a possibility to identify structure and systemize product knowledge in a unified product portfolio overview. It presents a step forward in establishing the proposed KBD framework because it discovers the (tacit) knowledge that is needed as an input and makes it possible to define standard designs as a base for the knowledge value stream. Hence, the contribution of this report to the existing body of knowledge within product architecting is shown as follows:

  1. (i)

    It outlines a concept for a transformational KBD approach applicable for ETO companies that aim to enforce more standardization and knowledge-reuse as a means to sustain competition.

  2. (ii)

    It launches a POC demonstrating a systematic process for finding, mapping, and structuring product variants as a lever for implementing the framework.

The proposed KBD model in Sect. 3 presents a method in which NPD knowledge can be integrated into an architectural product model and engineering design can be combined with a completely oriented KBD approach. Nevertheless, it should be noted that the implementation of this model is the long-term goal, but neither is the outcome proven nor can the results be generalized in the current state of this research. Therefore, further research should take a closer look into further implementation and testing of this model.